Table of Contents

TL;DR #

Can you host services in a native IPv6 world on AWS? Technically yes, but you’ll spend hours working around limitations that IPv4 solves instantly. The ecosystem isn’t ready.

I started this experiment while building the most cost-effective Immich setup on AWS. After hitting wall after wall, I gave up and switched back to IPv4. Here’s every obstacle I hit, so you can decide if it’s worth your time.

VPC Caveats #

IPv4 Is Still Required (Even for “IPv6-Only” Subnets) #

You can create an IPv6-only subnet, but AWS still forces you to attach an IPv4 CIDR block to your VPC. You’re not escaping IPv4; you’re just adding complexity.

S3 and DynamoDB Gateway Endpoints Default to IPv4 #

As of October 2025, you can create IPv6 gateway endpoints for S3 and DynamoDB, but only if you remember to enable IPv6 in the Additional Settings section during creation. Miss that checkbox and you’re stuck with IPv4.

AWS CLI Won’t Reach S3 Without Manual Configuration #

If you skip VPC endpoints, you’ll need to manually configure your AWS CLI profile to use dual-stack endpoints. Otherwise, DNS resolution defaults to IPv4 A records instead of IPv6 AAAA records, and your S3 calls fail.

aws configure set default.s3.use_dualstack_endpoint true
aws configure set default.s3.addressing_style virtual

Full documentation: https://docs.aws.amazon.com/AmazonS3/latest/API/dual-stack-endpoints.html

SSM Agent Doesn’t Work (And Your Boot Time Suffers) #

Systems Manager and Session Manager fail out of the box on IPv6-only instances. You’ll notice immediately: your instance takes 5+ minutes to boot while cloud-init times out trying to reach IPv4 metadata endpoints.

Here’s what you’ll see in the logs:

[    4.100818] cloud-init[579]: Cloud-init v. 25.2-0ubuntu1~24.04.1 running 'init-local' at Sat, 03 Jan 2026 12:45:33 +0000. Up 4.09 seconds.
[    5.850790] cloud-init[579]: 2026-01-03 12:45:34,794 - url_helper.py[WARNING]: Calling 'http://[fd00:ec2::254]/latest/api/token' failed [0/240s]: request error [HTTPConnectionPool(host='fd00:ec2::254', port=80): Max retries exceeded with url: /latest/api/token (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xea567360c3b0>: Failed to establish a new connection: [Errno 101] Network is unreachable'))]
[    7.002419] cloud-init[579]: 2026-01-03 12:45:35,945 - url_helper.py[WARNING]: Calling 'http://[fd00:ec2::254]/latest/api/token' failed [1/240s]: request error [HTTPConnectionPool(host='fd00:ec2::254', port=80): Max retries exceeded with url: /latest/api/token (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xea567360c3e0>: Failed to establish a new connection: [Errno 101] Network is unreachable'))]
[    8.153752] cloud-init[579]: 2026-01-03 12:45:37,097 - url_helper.py[WARNING]: Calling 'http://[fd00:ec2::254]/latest/api/token' failed [2/240s]: request error [HTTPConnectionPool(host='fd00:ec2::254', port=80): Max retries exceeded with url: /latest/api/token (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xea567360d9a0>: Failed to establish a new connection: [Errno 101] Network is unreachable'))]

                                                   
[   59.154818] cloud-init[579]: 2026-01-03 12:46:28,098 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/latest/api/token' failed [53/240s]: Request timed out
[  110.155734] cloud-init[579]: 2026-01-03 12:47:19,098 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/latest/api/token' failed [104/240s]: Request timed out

Use Tailscale to Actually Connect to Your Instance #

I’m lucky: I have native IPv6 at home because I chose my ISP with that in mind. Most people don’t.

If your ISP doesn’t support IPv6, you’ll need Tailscale to reach your instance. Tailscale creates a private network (Tailnet) that works regardless of your IP version, using carrier-grade NAT IPv4 addressing internally.

After installing Tailscale, add --ssh to your tailscale up command. This enables SSH access without opening ports on your security group. Your instance stays invisible to the public internet (even IPv6) while you can still reach it.

Bonus: Tailscale SSH lets you connect without managing SSH keys.

GitHub Doesn’t Support IPv6 (Yes, Really) #

As of January 2026, GitHub (owned by Microsoft, one of the largest cloud providers) still doesn’t support IPv6. You can’t clone repos or pull container images from their registry on an IPv6-only instance.

(from ProgrammerHumor) I’ve already discussed (and ranted about it) [here]: (https://damianogiorgi.it/articles/2026/01/are-we-on-ipv6-yet/) You should check also doesgithub.onipv6.work

The Workaround: Use a Free Proxy #

Daniel Winzen runs a free IPv6 proxy for GitHub. Follow the instructions at https://danwin1210.de/github-ipv6-proxy.php to access repos and container images.

This works, but relying on a third-party proxy for critical infrastructure isn’t ideal.

Containers Add Another Layer of Complexity #

Docker and Podman support IPv6 networking, but you’ll need to configure it manually in your Docker Compose files.

The real problem: Most self-hosted solutions pull images from GitHub’s container registry. You already know GitHub doesn’t support IPv6, so you’ll need that proxy workaround.

Worse, some services (like Immich) download additional data from GitHub at startup. To make this work, you must configure your containers to use the host’s /etc/hosts file. Otherwise they’ll try to reach GitHub directly and fail.

If your solution depends on other third-party APIs that don’t support IPv6, you’ll need to build custom proxy infrastructure. At that point, the complexity and cost outweigh any IPv6 benefits.

Enabling IPv6 for Containers #

Docker: Follow the official documentation to enable IPv6 networking. It’s straightforward.

Podman: Requires more configuration, but the Red Hat documentation walks you through it (once you find it).

Other AWS Services That Don’t Support IPv6 #

Full list: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-support.html

Notable gaps:

Systems Manager (as mentioned)
CodeBuild
Partial support in EKS and VPC Lattice
Outposts (though Direct Connect does support IPv6)

The Rest of the Internet Isn’t Ready Either #

GitHub isn’t alone. HuggingFace APIs, many SaaS tools, and countless other services remain IPv4-only.

Even on AWS, creating a load balancer defaults to IPv4. You can enable dual-stack, but most people don’t, so most hosted services stay IPv4-only.

IPv6 adoption requires effort. It can’t rely on individuals alone, but we as builders need to push for it. My home network runs dual-stack, yet many enterprises treat IPv6 as a nuisance while simultaneously complaining about NAT Gateway costs, dealing with overlapping CIDRs, and managing double-NAT setups.

NAT was supposed to be a temporary fix while we found a real solution. That solution exists: it’s IPv6. But I think the technology is ready while the people aren’t.

Let’s see if anything changes by next year.